набор записей с использованием

Question

Пожалуйста, подумайте, что сайт имеет мин. 30.000 посетителей в день.
Сайт был закодирован с использованием asp sql 2008

Есть так много строк и так много соединений с базой данных

Я использую набор записей следующим образом

set rs=server.createobject.......
set rs2=server.createobject.......
set rs3=server.createobject.......

Я поставил эти строки вверху страницы. тогда я использую их, когда мне нужно, как;

rs.open "select........."
rs.close

Я использую их, возможно, 3 раза для каждой страницы.

и внизу страницы пишу

set rs=nothing
set rs2=nothing
set rs3=nothing

---

Теперь мой вопрос: это вызывает утечку памяти или любую другую проблему?

или я должен использовать как

set rs=server.createobject
rs.open
rs.close
set rs=nothing

Я имею в виду, должен ли я создавать объект всякий раз, когда мне нужно, и убивать его, когда я заканчиваю с ним каждый раз

Answer 1

Лучше, если вы создадите наборы записей как отключенные от БД (освобождая соединение)

Dim rs, cmd
Set rs = server.createobject("ADODB.Recordset")
Set cmd = server.createobject("ADODB.Command")

' Init the ADO objects  & the stored proc parameters
cmd.ActiveConnection = GetConnectionString()
cmd.CommandText = sqlstmt
cmd.CommandType = adCmdText

' Execute the query for readonly
rs.CursorLocation = adUseClient
rs.Open cmd, , adOpenForwardOnly, adLockReadOnly


' Disconnect the recordset
Set cmd.ActiveConnection = Nothing
Set cmd = Nothing
Set rs.ActiveConnection = Nothing

Answer 2

Вообще говоря, вручную избавляться от наборов записей и других объектов слишком осторожно, особенно в конце страницы.

VBScript имеет встроенную сборку мусора и финализаторы. Как только на объект больше не ссылаются *, он будет GC'd и вызывается его class_terminate метод. Таким образом, если вы создаете набор записей внутри функции и не передаете ссылку за пределы функции, то она будет собрана, а ее ресурсы будут освобождены в конце функции, когда на нее больше нет ссылок. Если вы поместите объект в глобальную переменную, он все равно будет собран после завершения работы скрипта. Вы не можете вызвать утечку памяти таким способом. По этой причине удаление объектов в конце сценария бесполезно, так как они все равно не переживут конец сценария, если вы намеренно не поместите их в более долгоживущую коллекцию, например Session или Application.

.

* Сборка мусора в VBScript гарантирует быструю сборку, но, поскольку он учитывает только ссылки, его можно обмануть циклическими ссылками. Имейте это в виду, и это не должно доставлять вам хлопот.

Как правило, если существует объект, который вам нужен в течение короткого времени, ссылка на него в локальной переменной функции или в качестве объекта блока with является лучшим решением. Единственная причина для ручного сброса объекта состоит в том, что если а) у вас есть реальная, продемонстрированная необходимость высвободить ресурсы, или либо b1) на рассматриваемый объект ссылаются в глобальной области видимости после того, как он необходим, либо b2) объект является частью объекта. круговая ссылка.

Теперь, в вашем конкретном случае, похоже, что единственный ресурс, о котором стоит беспокоиться - это соединение с базой данных. Если ваша база данных не может справиться с нагрузкой, то быстрое прекращение соединений может помочь. Есть два способа сделать это. Во-первых, вручную сбросьте каждый набор записей, когда он вам больше не нужен, или вручную отключите соединение каждого набора записей. Во-вторых, используйте наборы записей или соединения в меньшем объеме, чтобы они автоматически обрабатывались. Если все, что вам нужно, это, например, данные, то вы можете использовать метод GetRows, чтобы получить данные без дополнительных затрат на хранение набора записей. В моем коде я никогда не работаю с наборами записей, командами или соединениями напрямую, а использую вспомогательные функции, которые заботятся о мрачных деталях ADO и возвращают нужные мне данные.

Answer 3

Технически вы должны уничтожать объекты как можно скорее.

При этом я делаю большинство своих страниц так же, как и вы, и у меня никогда не было проблем